Encryption key rotation framework

ABSTRACT

Techniques are described herein for efficiently and expeditiously performing key rotation and key replacement. In an embodiment, a key replacement request is received that specifies one or more key names of a plurality of key names. A location-to-key-name mapping that maps the plurality of key names to a plurality of encrypted-data locations is used to determine one or more encrypted-data locations that are mapped to the one or more key names. A first set of messages is generated where each message identifies a table that is associated with the one or more encrypted-data locations. The first set of messages is stored in a queue for processing by a first plurality of worker processes. Each worker process of the first plurality of worker processes retrieves a message of the first set of messages from the queue and generates a message of a second set of messages that identifies a subset of encrypted data records from the table identified in the message of the first set of messages. Each message of the second set of messages is stored in a distinct queue which is assigned to a worker process of a second plurality of worker processes. Each worker process of the second plurality of worker processes retrieves the message from the assigned queue, decrypts the subset of encrypted data records identified in the respective message, re-encrypts the decrypted data records using a new encryption key that corresponds to a new key name, and stores the re-encrypted data records in a database.

BENEFIT CLAIM

This application claims the benefit as a continuation of applicationSer. No. 16/711,132, filed Dec. 11, 2019, by Mohsin Roowalla et al., theentire contents of which is hereby incorporated by reference. Theapplicant hereby rescinds any disclaimer of claim scope in the parentapplications or the prosecution history thereof and advise the USPTOthat the claims in this application may be broader than any claim in theparent application.

FIELD OF THE INVENTION

The technical field to which the present disclosure generally relates iscomputer software in the field of information security. The technicalfield also includes secure key rotation for encrypted data inclient-server systems.

BACKGROUND

Data records, such as customer data records, can be encrypted using anencryption key and stored in a database in encrypted form. An encryptionkey may be associated with human readable text that represents an aliasof the encryption key, referred to herein as a “key name”. In somecases, a key name refers to a single encryption key. In other cases, akey name refers to a version of an encryption key. When a key namerefers to a version of an encryption key, there can be multiple versionsof the same encryption key. A value can be stored that keeps track of acurrent version of an encryption key, referred to herein as a “keyversion”. When there are many versions of an encryption key, only thecurrent version of the encryption key can be used to decrypt encrypteddata.

In some embodiments, users or services can use the encryption key thatwas initially used to encrypt data records to decrypt the encrypted datarecords. Unauthorized users that do not possess the appropriateencryption key will not be able to decrypt the data, even if they find away to access it. For purposes of data security, an information securityoperator or administrator may desire to periodically change theencryption keys or versions of encryptions keys that are associated withencrypted data records. The changing of the key names and correspondingencryption keys that are used to encrypt data in a database is referredto herein as “key replacement”. The changing the versions of encryptionkeys that are used to encrypt data in a database is referred to hereinas “key rotation”.

Performing both key rotation and key replacement may include the stepsof decrypting encrypted data records using the encryption key that wasused to encrypt the encrypted data records and then re-encrypting thedecrypted data records using a new encryption key or new version of anencryption key. For databases that store large amounts of data, rotatingor replacing the encryption keys of large amounts of encrypted datarecords can require a substantial amount of compute resources and asignificant amount of time to complete.

In an event such as a security breach where encryption keys arecomprised by malicious actors, the time required to re-encrypt all ofthe data records with new encryption keys or new versions of encryptionkeys provides a golden opportunity for malicious actors to compromisedata. Additionally, current key rotation and replacement techniquesrequire significant database downtime that prevents services and clientsof from accessing data stored in a database while such techniques arebeing performed.

Thus, techniques to quickly and efficiently rotate and replaceencryption keys are desired.

The approaches described in this section are approaches that could bepursued, but not necessarily approaches that have been previouslyconceived or pursued. Therefore, unless otherwise indicated, it shouldnot be assumed that any of the approaches described in this sectionqualify as prior art merely by virtue of their inclusion in thissection.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings:

FIG. 1 is a block diagram illustrating a system for encryption keyrotation framework, according to an embodiment.

FIG. 2 illustrates a graphical user interface (GUI) that is used togenerate a location-to-key-name mapping, according to an embodiment.

FIG. 3 illustrates a GUI that is used to generate key rotation and keyreplacement requests, according to an embodiment.

FIG. 4 is a block diagram illustrating a system for parallelized keyrotation and key replacement, according to an embodiment.

FIG. 5 is a flowchart illustrating steps for parallelized keyreplacement, according to an embodiment.

FIG. 6 is a block diagram of a computer system that may be used toimplement the techniques described herein.

DETAILED DESCRIPTION

In the following description, for the purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the present invention. It will be apparent, however,that the present invention may be practiced without these specificdetails. In other instances, well-known structures and devices are shownin block diagram form in order to avoid unnecessarily obscuring thepresent invention.

General Overview

Techniques are described herein for efficiently and expeditiouslyperforming key rotation and key replacement. Specifically, assume a keyreplacement request is received that specifies to replace encryptionkeys of encrypted data records in a database. According to oneembodiment, a key replacement system that manages the key replacementprocedure first determines a set of database tables that includeencrypted data records to have their encryption keys replaced. A workerprocess is assigned to each table and segments each respective tableinto subsets of encrypted data records. A worker process is assigned toeach subset of encrypted data records to decrypt the encrypted datarecords with an old encryption key and re-encrypt the decrypted datarecords with a new encryption key. The amount of encrypted data recordsassigned to each worker process can be configured by an informationsecurity administrator such that computing resources for any givensystem can even distributed with the goal of minimizing system downtownwhen performing key replacement operations.

Furthermore, techniques are provided for performing key rotation. Assumea key a key rotation request is received that specifies to rotateversions of encryption keys of encrypted data records in a database.According to one embodiment, a key rotation system that manages the keyrotation procedure first retrieves encrypted data records that arestored in a database. Each encrypted data record comprises a compositevalue that includes a key name, key version, and encrypted payload data.The composite values of the encrypted data records are queried todetermine if any of the encrypted data records include a key versionthat matches a source key version specified in the key rotation request.When a matching encrypted data record is found, the encrypted payloaddata of the encrypted data record is decrypted using an encryption keythat corresponds to the source key version. The decrypted payload datais then re-encrypted using a new version of the encryption key. Thecomposite value of the re-encrypted data record is updated to include areference to the new version of the encryption key.

By representing data records with composite values that include keynames, key versions, and encrypted payload data, encrypted data recordsare provided with enhanced indexing that allows highly granularsegmenting of encrypted data records for future access within a row orcolumn of a database table.

System Overview

FIG. 1 is a block diagram illustrating a system for encryption keyrotation framework. Various devices 102-114 are coupled to a network 116in the system 100. The network 116 may be an internet, intranet, privatenetwork, or any other appropriate network or combination of networks,include other networks described herein.

At least one client computing system 102 is coupled to the network 116.Although a single client computer system 102 is depicted in FIG. 1 , ina practical environment there may be many more, perhaps hundreds orthousands, of client computer systems coupled to network 116. Clientcomputer system 102 may execute programmatic instructions that comprisea client application to communicate with other devices of the network102. For example, a client application executing on client computersystem 102 may execute a web browser client to communicate with webserver 104, key rotation system (KRS) 112, key rotation (KR) API KR APIservice 106, database management system (DBMS) 108, and/or keymanagement system (KMS) 114 via network 116.

Web server 104, upon receiving a request from client computing system102, interacts with KR API service 106, for example, by making a call toan API associated with KR API service 106. KR API service 106 maycomprise and execute programmatic instructions to carry out specifictasks associated with the respective service. For example, KR APIservice 106 may execute a programmatic task to validate and publish keyrotation request message to key rotation request queue and store keyrotation request state or status in KR API service 106 database. KRS 112may function as a database client and execute instructions to connectwith DBMS 108, transmit digital data to DBMS 108, and issue queries toDBMS 108. Although a single KR API service is depicted in FIG. 1 , in apractical environment there may be many more services coupled to network116.

DBMS 108 may comprise a database server (not shown) and a database 110.DBMS 108 may receive requests to store data records in database 110 fromvarious devices of the system 100. The DBMS 108 may also receive queriesfor data records that is stored the database 110. A database serverassociated with DBMS 108 may store data records based on requests tostore data records and retrieve data records based on requests to accessdata records. The database 110 may comprise any appropriate storage,including network attached storage, a shared file system, a database,etc.

Programmatic KMS 114 generates, manages and verifies encryption keys andcorresponding key names for devices of the system to access data recordsfrom DBMS 108. For example, when storing data records in the DBMS 108, asystem device such as web server 104 or KR API service 106 may issue arequest to KMS 114 to retrieve an encryption key for use in encryptingthe data records. In some embodiments, an encryption key is retrievedfrom KMS 114 by providing a key name and key version in a request to KMS114. KMS 114 may use the key name provided in the request to locate acorresponding encryption key that is managed by KMS 114. Additionally,when attempting to access data records stored in DBMS 108, a systemdevice such as the web server 104 or KR API service 106 may communicatewith KMS 114 to retrieve an encryption key for decrypting the datarecords. An example of an enterprise KMS is KeySecure by SafeNet.

KRS 112 may comprise one or more server computers or other computingdevices that execute programmatic instructions to perform key rotationand key replacement operations, as discussed herein. KRS 112 maycommunicate with DBMS 108 to retrieve data records, encrypt datarecords, decrypt encrypted data records, re-encrypt decrypted datarecords, and update re-encrypted data records in the DBMS 108. KRS 112may communicate with KMS 114 to retrieve encryption keys that correspondto key names and key versions provided in a request to KMS 114.Additional details are discussed herein.

Data Record Format

As discussed above, DBMS 108 stores data records in database 110. In oneembodiment, each data record (row) comprises a field (column) thatcontains a composite value. Specifically, according to one embodiment,each data record has a field containing a composite value includes (a) akey name, (b) a key version, and (c) payload data. The key namerepresents an alias of an encryption key that is used to encrypt thepayload data of the data record. The key version specifies a value thatidentifies a version of an encryption key that is used to encrypt thepayload data of the data record. The payload data refers to substantivedata of the respective composite value and may represent sensitiveconsumer data relating to one or more applications or services.

Payload data for a data record may be encrypted using an encryption keythat corresponds to the key name and key version included in thecomposite value of the respective data record. Once the payload data fora data record is encrypted, the data record may be stored in a databaseand referred to as an “encrypted data record”. The payload data of anencrypted data record may be decrypted using an encryption key thatcorresponds to the key name and key version included in the encrypteddata record. Once the payload data of an encrypted data record isdecrypted, the data record may be stored in a database and referred toas a “decrypted data record”.

As an example, the string “{key, 1}cLd5EFRtoeJ5wOtiu0C92w==” representsa composite value of an encrypted data record. The text ‘key’ is the keyname of the composite value. The text ‘1’ is the key version of thecomposite value. The text ‘cLd5EFRtoeJ5wOtiu0C92w==’ is the payload dataof the composite value. The payload data ‘cLd5EFRtoeJ5wOtiu0C92w==’ isrepresented by an encrypted data value.

Location-to-Key-Name Mapping

A location-to-key-name mapping maps the location of data records storedin a database to key names. A location-to-key-name mapping comprises oneor more location-to-key-name entries. Each location-to-key-name entry ofa location-to-key-name mapping specifies an encrypted-data location anda corresponding key name. For a location-to-key-name entry, theencrypted-data location specifies the location of data records that wereencrypted with the encryption that corresponds to the key name from thelocation-to-key-name entry.

An encrypted-data location may identify a specific column in a specificdatabase table with a specific database schema. The format of anencrypted-data location may be based on a schema associated with adatabase table and may vary among different database implementations. Insome embodiments, an encrypted-data location follows the nameconvention: “schema_name.table_name.column_name”.

An example location-to-key-name entry may specify that‘table$person.firstname’ is mapped to ‘key1’. In this example of alocation-to-key-name entry, the key name is: ‘key1’, and the data thatis encrypted using the encryption key corresponding to that key nameresides at encrypted-data location: ‘table$person.firstname’. Theencrypted-data location specifies the database schema ‘table’, thedatabase table ‘table$person, and the column ‘firstname’.

A location-to-key-name mapping can be generated by a privileged usersuch as an information security administrator. FIG. 2 illustrates agraphical user interface (GUI) that is used to generate alocation-to-key-name mapping. For example, a privileged user usingclient computing system 102 or KR API service 106 can enter anencrypted-data location 202, a key name 204, and a key locator type 206to create an entry in location-to-key-name mapping 208.Location-to-key-name mapping 208 includes three location-to-key-namemapping entries 210, 212, 214. Each location-to-key-name mapping entry210, 212, 214 includes data fields for a schema name, table name,encrypted-data location (i.e. key locator name in FIG. 2 ), key name,and key locator type.

For example, location-to-key-name entry 210 includes a ‘table’ schemaname, a ‘table$person table name, a ‘table$person.firstname’encrypted-data location, a ‘key1’ key name, and ‘Stored Data’ keylocator type. Thus, location-to-key-name entry 210 indicates that userdata located at ‘table$person.firstname’ is to be encrypted using theencryption key associated with key name “key1”.

Location-to-key-name entry 212 includes a ‘table; schema name, a‘table$person’ table name, a ‘table$person.lastname’ key locator name, a‘key2’ key name, and ‘Stored Data’ key locator type. Thus,location-to-key-name entry 212 indicates that user data located at‘table$person.lastname’ is to be encrypted using the encryption keyassociated with key name ‘key2’. As is clear by entries 210 and 212, thesame encryption key (e.g. the encryption key named ‘key2’) can be usedto encrypt data a various locations within the database.

Location-to-key-name entry 214 includes an ‘address’ key locator name, a‘key3’ key name, and ‘Transfer Data’ key locator type. Alocation-to-key-name mapping may also be cached for quick access andstored in association with any device of the system of FIG. 1 .

Key Rotation

A privileged user such as an information security administrator maygenerate a key rotation request. The request may specify a source keyversion that is to be rotated and a target key version that the sourcekey version is to be rotated to. The request may also specify a sourcekey name that is to be rotated and a target key name that the source keyname is to be rotated to.

FIG. 3 illustrates a graphical user interface (GUI) that is used togenerate a key rotation request. For example, a privileged user usingclient computing system 102 or KR API service 106 can generate a requestto rotate source key versions to target key versions. As shown, SourceKey Version: ‘CURRENT’ 302 is to be rotated to Target Key Version:‘LATEST’ 304 and Source Key Name: ‘CURRENT’ 306 is to be rotated toTarget Key Name: ‘CURRENT 308. Such a request indicates that all currentkey versions of encryption keys should be rotated to target (i.e. new)versions of encryption keys. Because the source key name 306 and targetkey name 308 are set to the identical values of ‘CURRENT’, the requestindicates that all current key names of all encryption keys should staythe same. A privileged user may also specify specific key versions torotate. For example, a privileged user may specify to rotate Source KeyVersion: ‘1’ to Target Key Version: ‘2’

The GUI shown in FIG. 3 allows a privileged user to select parameters toinclude in a key rotation request. Additionally, the GUI shown in FIG. 3allows a privileged user to select events 310, workers (i.e. processesthat will execute the desired key rotation procedure) 312, andencrypted-data locations 314 of data records that to include in arequest. On selection of ‘Run Key Rotation’ 316, a key rotation requestwith the selected parameters is generated.

Once a key rotation request is configured and generated, the request istransmitted to KRS 112 for processing. When KRS 112 receives a keyrotation request, KRS 112 parses the request and determines one or moreencrypted-data locations. Determining one or more encrypted-datalocations may include KRS 112 querying all key names specified in therequest against the location-to-key-name mapping stored in DBMS 108 toretrieve one or more encrypted-data locations that are mapped to the keynames specified in the request. For example, since the GUI shown in FIG.3 is configured with the source key name 306 and target key name 308 setto ‘CURRENT’, all encrypted-data locations in the location-to-key-namemapping will be retrieved because the ‘CURRENT’ 306 to ‘CURRENT’ 308configuration includes all possible key names.

One or more encrypted data records stored at the one or moreencrypted-data locations are then retrieved for processing. Compositevalues associated with each of the one or more encrypted data recordsare examined to determine the key version of each respective encrypteddata record. The key versions of the composite values of the one or moreencrypted data records are compared against the key version specified inthe request. If the key version specified in the request matches the keyversion of a composite value of a particular encrypted data record, theparticular data record is selected for key rotation. For example, sincethe GUI shown in FIG. 3 is configured with the source key version 302set to ‘CURRENT’ and target key version 304 set to ‘LATEST’, all datarecords will be selected for key rotation.

The key name and key version from the composite values of each of theone or more encrypted data records are used to retrieve thecorresponding encryption keys from KRS 112 and decrypt each of one ormore encrypted data records, thereby generating one or more decrypteddata records. For example, for each encrypted data record, the key nameand key version from the composite value of the respective encrypteddata record is used to retrieve the corresponding encryption key fromKRS 112 that is used to decrypt the respective encrypted data record.

The composite values of the one or more decrypted data records are thenupdated to include the target key version specified in the request. Oncethe composite values of the one or more decrypted data records areupdated, one or more re-encrypted data records are generated byencrypting the one or more decrypted data records using an encryptionkey that corresponds to the target key version of the respective updateddecrypted data record. The one or more re-encrypted data records arethen stored at the encrypted-data location that is mapped to the keyname of the respective re-encrypted data record.

Key rotation techniques discussed herein provide enhancements overprevious techniques. For example, by appending a key version to acomposite value of a decrypted or unencrypted data record, data recordsthat are stored in the same table, row, or column in a database can havethe same key name, but different key versions. Thus, instead of merelyidentifying data records by key names, key versions provide anotherlayer of indexing for data records and allow highly granular segmentingof such data records for future access within a row or column of adatabase table.

Key Replacement

A privileged user such as an information security administrator maygenerate a key replacement request. The request may specify a source keyname that is to be replaced and a target key name that the source keyname is to be replaced by.

As discussed above, FIG. 3 illustrates a graphical user interface (GUI)that is used to generate a key replacement request. For example, aprivileged user using client computing system 102 or KR API service 106can generate a request to rotate source key names to target key names.As shown, Source Key Name: ‘CURRENT’ 306 is to be rotated to Target KeyName: ‘CURRENT’ 308. In the particular example shown in FIG. 3 , becausethere is no difference between the ‘Source Key Name’ 306 and ‘Target KeyName’ 308 fields, performing a key name rotation will have no impact.However, a privileged user may specify to rotate the ‘Source Key Name’306 to any applicable ‘Target Key Name’ 308.

Parameters such as events 310, workers 312, and encrypted-data locations314 can be selected to be included in a key replacement request by usingthe GUI, as discussed with respect to ‘Key Version Rotation’. Onselection of ‘Run Key Rotation’ 316, a key replacement request with theselected parameters is generated.

Once a key replacement request is configured and generated, the requestis transmitted to KRS 112 for processing. When KRS 112 receives a keyreplacement request, KRS 112 parses the request and determines one ormore encrypted-data locations. Determining one or more encrypted-datalocations may include KRS 112 querying all key names specified in therequest against the location-to-key-name mapping stored in DBMS 108 toretrieve one or more encrypted-data locations that are mapped to the keynames specified in the request.

One or more encrypted data records stored at the one or moreencrypted-data locations are then retrieved for processing. In someembodiments, composite values associated with each of the one or moreencrypted data records are examined to determine the key name of eachrespective encrypted data record. The key names of the one or moreencrypted data record are used to retrieve the corresponding encryptionkeys from KRS 112 and decrypt each respective encrypted data record ofthe one or more encrypted data records, thereby generating one or moredecrypted data records.

The composite values of the one or more decrypted data records are thenupdated to include the target key name specified in the request. Oncethe composite values of the one or more decrypted data records areupdated, one or more re-encrypted data records are generated byencrypting the one or more decrypted data records using an encryptionkey that corresponds to the target key name of the respective updateddecrypted data record. The one or more re-encrypted data records arethen stored at the encrypted-data location that is mapped to the keyname of the respective re-encrypted data record. An information securityadministrator using client computing system 102 may update thelocation-to-key-name mapping so that the existing encrypted-datalocations are mapped to the target key names.

Parallelized Key Rotation and Key Replacement

FIG. 4 is a block diagram illustrating a system for parallelized keyrotation and key replacement. The system of FIG. 4 is utilized toperform key rotation and key replacement quickly and efficiently.

The system of FIG. 4 operates by receiving a key rotation or keyreplacement request at KR API service 106. For a key replacementrequest, KR API service 106 parses the request and identifies one ormore key names included in the request. For a key rotation request, KRAPI service 106 parses the request and identifies one or more key namesand one or more key versions included in the request. KR API service 106uses the location-to-key-name mapping to determine one or moreencrypted-data locations that are mapped to the one or more key namesincluded in the request.

Based on the one or more encrypted-data locations, KR API service 106generates a first set of messages that includes a message for each tableassociated with the one or more encrypted-data locations and publishesthe first set of messages to primary queue 402. In some embodiments,each message of the first set of messages includes an assignment to atable worker 404, 406, 408. Each table worker 404, 406, 408 comprisesone or more processes, such as an instance of programmatic instructionsthat retrieve or extract the unique IDs of each encrypted data recordspecified by the location-to-key-name mapping. Each table worker 404,406, 408 may be executed by separate server computers or all tableworkers may collectively be executed by a single server computer.Although only three table workers 404, 406, 408 are depicted in FIG. 4 ,in a practical environment there may be many more, perhaps hundreds orthousands, of table workers.

Each table worker 404, 406, 408 retrieves a message of the first set ofmessages from primary queue 402, retrieves unique IDs of encrypted datarecords, and calculates a total count of encrypted data records that areincluded in the table that is identified in the message that wasretrieved by the respective table worker. Each table worker 404, 406,408 then generates one or more messages of a second set of messages thateach identify a subset of encrypted data records that are included inthe table that is identified in the message that was retrieved by therespective table worker.

A subset of encrypted data records may identify one or more encrypteddata records. An amount of encrypted data records included in a subsetof encrypted data records may depend on the amount of records includedin the table that is identified in: the message that is assigned to orprocessed by the respective table worker or a configuration fileassociated with the respective table worker. An information securityadministrator may configure an amount of encrypted data records includedin each subset of encrypted data records so that systems can adjust andvariate the use of available system computing resources.

In some embodiments, each message of the second set of messages includesan assignment to one or more record workers 416, 418, 420. Similar totable workers 404, 406, 408, although only three record workers 416,418, 420 are depicted in FIG. 4 , in a practical environment there maybe many more, perhaps hundreds or thousands, of record workers. Eachmessage of the second set of messages is then published by table workers404, 406, 408 in a respective queue 410, 412, 414.

Each record worker 416, 418, 420 retrieves a message from the second setof messages from queue 410, 412, 414 and queries the database table forthe subset of encrypted data records that is identified in therespective message. Each record worker 416, 418, 420 then performs keyrotation or key replacement operations on the respective subset ofencrypted data records which may include decrypting the respectivesubset of encrypted data records, updating key names and/or key versionsof the decrypted data records, re-encrypting the updated decrypted datarecords, and updating the re-encrypted data records in database 422. Insome embodiments, database 422 may comprise database 110 from FIG. 1 .

If a record worker 416, 418, 420 encounters a failure or error duringexecution, the respective record worker may roll back the entire update,generate and publish a retry message that identifies the failure toretry queue 424. Retry worker 426 may retrieve the retry message andrepublish the failure message to a queue 410, 412, 414 for retry andstore a retry count in database 428. In some embodiments, database 428may comprise database 422 or database 110 from FIG. 1 .

When a maximum number of retries are exhausted, the retry worker willgenerate and publish a failure message and the corresponding failuremessage may be published to dead letter queue 430. Failure worker 432may retrieve the failure message from the dead letter queue 430 andstore the failure message in an error table in database 428 forinvestigation by an information security administrator. After resolvingthe failure message, the failure message may be published to one ofqueues 410, 412, 414 to re-process the failure message.

Example Parallelized Key Replacement Procedure

FIG. 5 is a flowchart illustrating parallelized key replacement,according to an embodiment. FIG. 5 and each other flow diagram hereinillustrates an algorithm or plan that may be used as a basis forprogramming one or more of the functional modules of FIG. 1 and FIG. 4that relate to the functions that are illustrated in the diagram, usinga programming development environment or programming language that isdeemed suitable for the task. Thus, FIG. 5 and each other flow diagramherein are intended as an illustration at the functional level at whichskilled persons, in the art to which this disclosure pertains,communicate with one another to describe and implement algorithms usingprogramming. The flow diagrams are not intended to illustrate everyinstruction, method object or sub step that would be needed to programevery aspect of a working program, but are provided at the high,functional level of illustration that is normally used at the high levelof skill in this art to communicate the basis of developing workingprograms. For purposes of illustrating a clear example, FIG. 5 and otherflow diagrams are discussed in the context of FIG. 1 and FIG. 4 , butthe algorithms of FIG. 5 and the other flow diagrams also can beimplemented in other contexts.

In step 502, a location-to-key-name mapping that maps a plurality of keynames to a plurality of encrypted-data locations is stored. For example,a location-to-key-name mapping, as discussed in detail in the sectiontitled ‘LOCATION-TO-KEY-NAME MAPPING’ herein is created and stored indatabase 110.

In step 504, a key replacement request is received. The request mayspecify one or more key names of the plurality of key names. Forexample, KR API service 106 receives a key replacement request. Therequest may initially be generated at client computing system 102 or KRAPI service 106 via GUI by a privileged user such as an administrator asdiscussed in detail in the section titled ‘KEY NAME ROTATION’.

In step 506, using the location-to-key-name mapping, one or moreencrypted-data locations of the plurality of encrypted-data locationsare determined based on the one or more key names of the plurality ofkey names. For example, once KR API service 106 parses the keyreplacement request and determines which encrypted-data locations aremapped to the one or more key names specified in the request received instep 504.

In step 508, a first set of messages is generated. Each message of thefirst set of messages identifies a table that is associated with the oneor more encrypted-data locations of the plurality of encrypted-datalocations. In some embodiments, each message of the first set ofmessages is assigned to a worker process of a first plurality of workerprocesses. For example, once KR API service 106 determines one or moreencrypted-data locations such as in step 506, KR API service 106generates a message for each of the one or more encrypted-data locationsand corresponding table, assigns each message of the first set ofmessages to a table worker process 404, 406, 408 and publishes the firstset of messages to primary queue 402.

In step 510, a second set of messages is generated based on the firstset of messages. Each message of the second set of messages identifies asubset of encrypted data records from the table identified in therespective message of the first set of messages. In some embodiments,each message of the second set of messages each is assigned to a workerprocess of a second plurality of worker processes. For example, eachtable worker process 404, 406, 408 retrieves a message of the first setof messages from primary queue 402, and based on the respective message,generates one or more messages of a second set of messages that eachidentify a subset of encrypted data records included in the tableidentified in the respective message of the first set of messages. Eachtable worker process may assign each message of the second plurality ofmessages to a record worker process 416, 418, 410, for example, bystoring each message of the second set of messages in queues 410, 412,414, each of which are associated with one or more record workerprocesses 416, 418, 420.

In some embodiments, an amount of records included in a subset ofencrypted data records may be based on an amount of encrypted datarecords included in a table identified in a message of the first set ofmessages. For example, each table worker process 404, 406, 408 retrievesthe message of the first set of messages assigned to the respectivetable worker process 404, 406, 408 from primary queue 402 and determinesan amount of encrypted data records included in the table identified inthe respective message. To determine an amount of encrypted data recordsincluded in the tables identified in the respective message, eachrespective table worker process 404, 406, 408 may submit queries to eachtable to determine how many records are in each table.

In step 512, decrypted data records are generated. Decrypted datarecords are generated by each worker process of the second plurality ofworker processes decrypting the subset of encrypted data recordsidentified in the message of the second set of messages that is assignedto the respective worker process of the second plurality of processes.Each decrypted data record is generating by using an encryption key thatcorresponds to the key name from the composite value of the respectiveencrypted record that is a target of decryption. For example, eachrecord worker process 416, 418, 420 retrieves the message of the secondset of messages assigned to the respective record worker process 416,418, 420 from queues 410, 412, 414 and generates decrypted data recordsby decrypting the subset of encrypted data records identified in therespective assigned message.

In step 514, re-encrypted data records are generated. Re-encrypted datarecords are generated by each worker process of the second plurality ofworker processes encrypting the decrypted data records that therespective worker process decrypted in step 512. Each re-encrypted datarecord is generated by using a new encryption key that corresponds to anew key name to encrypt the decrypted data records that were generatedin step 512. For example, each record worker process 416, 418, 420generates re-encrypted data records by encrypting the decrypted datarecords that were generated by the respective worker process 416, 418,420 in step 512.

In some embodiments, the new key names that correspond to the newencryption keys that are used to encrypt the decrypted data records areused to update the location-to-key-name mapping that maps the pluralityof key names to the plurality of encrypted-data locations. The updatemay be initiated and executed by an information security administratorthrough client computing system 102.

In some embodiments, when a failure or error is detected during steps512-514, a failure message is generated. The failure message is assignedto a distinct worker process of the second plurality of worker processesfor retry. For example, a record worker 416, 418, 420 generates andpublishes a failure message that identifies a detected failure to retryqueue 424. Retry worker 426 retrieves the failure message andrepublishes the failure message to queue 410, 412, 414 for retry.

In some embodiments, when a retry message is generated, a retry count isgenerated based on the retry message and stored in a database. A retrycount identifies an amount of times that a particular message, orcontents of the particular message, was processed, or attempted to beprocessed, by a worker process. When it is determined that a retry countfor a retry message is greater than a threshold value, a failure messageis stored in a database for manual review. For example, retry worker 426uses KR API service 106 to store a retry count in database 428. When amaximum number of retries are exhausted, retry worker 426 publishes afailure message to dead letter queue 430. Failure worker 432 retrievesthe failure message from the dead letter queue 430 and uses KR APIservice 106 to store the failure message in an error table in database428 for investigation by an information security administrator. Afterresolving the failure message, the failure message may be published toone of queues 410, 412, 414 to re-process the failure message.

Using the techniques discusses herein, database system downtime whileencryption keys are being rotated or replaced is minimized. Byautomatically generating and distributing tasks for a resource intensivekey rotation or replacement procedure to a scalable amount of processes,a key rotation or replacement procedure can be executed with little tono downtime, which allows database clients continuous, uninterruptedaccess to data. Additionally, by using distributed and/or parallelprocessing techniques to distribute a key rotation or replacementworkload to multiple processes, a key rotation or replacement procedurecan be accomplished efficiently by using less compute, memory, andnetwork bandwidth than previous techniques.

Furthermore, techniques discussed herein for automatically handling andretrying errors and failures detected during the key rotation orreplacement procedure provide further enhancements on previoustechniques, which previously required manual identification and retryingof exceptions and errors occurring during a key rotation or replacementprocedure.

Hardware Overview

According to one embodiment, the techniques described herein areimplemented by one or more special-purpose computing devices. Thespecial-purpose computing devices may be hard-wired to perform thetechniques, or may include digital electronic devices such as one ormore application-specific integrated circuits (ASICs) or fieldprogrammable gate arrays (FPGAs) that are persistently programmed toperform the techniques, or may include one or more general purposehardware processors programmed to perform the techniques pursuant toprogram instructions in firmware, memory, other storage, or acombination. Such special-purpose computing devices may also combinecustom hard-wired logic, ASICs, or FPGAs with custom programming toaccomplish the techniques. The special-purpose computing devices may bedesktop computer systems, portable computer systems, handheld devices,networking devices or any other device that incorporates hard-wiredand/or program logic to implement the techniques.

For example, FIG. 6 is a block diagram that illustrates a computersystem 600 upon which an embodiment of the invention may be implemented.Computer system 600 includes a bus 602 or other communication mechanismfor communicating information, and a hardware processor 604 coupled withbus 602 for processing information. Hardware processor 604 may be, forexample, a general purpose microprocessor.

Computer system 600 also includes a main memory 606, such as a randomaccess memory (RAM) or other dynamic storage device, coupled to bus 602for storing information and instructions to be executed by processor604. Main memory 606 also may be used for storing temporary variables orother intermediate information during execution of instructions to beexecuted by processor 604. Such instructions, when stored innon-transitory storage media accessible to processor 604, rendercomputer system 600 into a special-purpose machine that is customized toperform the operations specified in the instructions.

Computer system 600 further includes a read only memory (ROM) 608 orother static storage device coupled to bus 602 for storing staticinformation and instructions for processor 604. A storage device 610,such as a magnetic disk, optical disk, or solid-state drive is providedand coupled to bus 602 for storing information and instructions.

Computer system 600 may be coupled via bus 602 to a display 612, such asa cathode ray tube (CRT), for displaying information to a computer user.An input device 614, including alphanumeric and other keys, is coupledto bus 602 for communicating information and command selections toprocessor 604. Another type of user input device is cursor control 616,such as a mouse, a trackball, or cursor direction keys for communicatingdirection information and command selections to processor 604 and forcontrolling cursor movement on display 612. This input device typicallyhas two degrees of freedom in two axes, a first axis (e.g., x) and asecond axis (e.g., y), that allows the device to specify positions in aplane.

Computer system 600 may implement the techniques described herein usingcustomized hard-wired logic, one or more ASICs or FPGAs, firmware and/orprogram logic which in combination with the computer system causes orprograms computer system 600 to be a special-purpose machine. Accordingto one embodiment, the techniques herein are performed by computersystem 600 in response to processor 604 executing one or more sequencesof one or more instructions contained in main memory 606. Suchinstructions may be read into main memory 606 from another storagemedium, such as storage device 610. Execution of the sequences ofinstructions contained in main memory 606 causes processor 604 toperform the process steps described herein. In alternative embodiments,hard-wired circuitry may be used in place of or in combination withsoftware instructions.

The term “storage media” as used herein refers to any non-transitorymedia that store data and/or instructions that cause a machine tooperate in a specific fashion. Such storage media may comprisenon-volatile media and/or volatile media. Non-volatile media includes,for example, optical disks, magnetic disks, or solid-state drives, suchas storage device 610. Volatile media includes dynamic memory, such asmain memory 606. Common forms of storage media include, for example, afloppy disk, a flexible disk, hard disk, solid-state drive, magnetictape, or any other magnetic data storage medium, a CD-ROM, any otheroptical data storage medium, any physical medium with patterns of holes,a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip orcartridge.

Storage media is distinct from but may be used in conjunction withtransmission media. Transmission media participates in transferringinformation between storage media. For example, transmission mediaincludes coaxial cables, copper wire and fiber optics, including thewires that comprise bus 602. Transmission media can also take the formof acoustic or light waves, such as those generated during radio-waveand infra-red data communications.

Various forms of media may be involved in carrying one or more sequencesof one or more instructions to processor 604 for execution. For example,the instructions may initially be carried on a magnetic disk orsolid-state drive of a remote computer. The remote computer can load theinstructions into its dynamic memory and send the instructions over atelephone line using a modem. A modem local to computer system 600 canreceive the data on the telephone line and use an infra-red transmitterto convert the data to an infra-red signal. An infra-red detector canreceive the data carried in the infra-red signal and appropriatecircuitry can place the data on bus 602. Bus 602 carries the data tomain memory 606, from which processor 604 retrieves and executes theinstructions. The instructions received by main memory 606 mayoptionally be stored on storage device 610 either before or afterexecution by processor 604.

Computer system 600 also includes a communication interface 618 coupledto bus 602. Communication interface 618 provides a two-way datacommunication coupling to a network link 620 that is connected to alocal network 622. For example, communication interface 618 may be anintegrated services digital network (ISDN) card, cable modem, satellitemodem, or a modem to provide a data communication connection to acorresponding type of telephone line. As another example, communicationinterface 618 may be a local area network (LAN) card to provide a datacommunication connection to a compatible LAN. Wireless links may also beimplemented. In any such implementation, communication interface 618sends and receives electrical, electromagnetic or optical signals thatcarry digital data streams representing various types of information.

Network link 620 typically provides data communication through one ormore networks to other data devices. For example, network link 620 mayprovide a connection through local network 622 to a host computer 624 orto data equipment operated by an Internet Service Provider (ISP) 626.ISP 626 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the“Internet” 628. Local network 622 and Internet 628 both use electrical,electromagnetic or optical signals that carry digital data streams. Thesignals through the various networks and the signals on network link 620and through communication interface 618, which carry the digital data toand from computer system 600, are example forms of transmission media.

Computer system 600 can send messages and receive data, includingprogram code, through the network(s), network link 620 and communicationinterface 618. In the Internet example, a server 630 might transmit arequested code for an application program through Internet 628, ISP 626,local network 622 and communication interface 618.

The received code may be executed by processor 604 as it is received,and/or stored in storage device 610, or other non-volatile storage forlater execution.

In the foregoing specification, embodiments of the invention have beendescribed with reference to numerous specific details that may vary fromimplementation to implementation. The specification and drawings are,accordingly, to be regarded in an illustrative rather than a restrictivesense. The sole and exclusive indicator of the scope of the invention,and what is intended by the applicants to be the scope of the invention,is the literal and equivalent scope of the set of claims that issue fromthis application, in the specific form in which such claims issue,including any subsequent correction.

What is claimed is:
 1. A computer-implemented method for key rotation,comprising: storing one or more encrypted data records at one or moreencrypted-data locations of a plurality of encrypted-data locations;wherein each encrypted data record of the one or more encrypted datarecords comprises a composite value that includes a key name and a keyversion; receiving a key rotation request that specifies: a source keyname, a source key version, and a target key name; wherein the sourcekey name is one of a plurality of key names; in response to receivingthe key rotation request: identifying a particular encrypted data recordof the one or more encrypted data records; wherein the particularencrypted data record is associated with: a particular key name thatmatches the source key name, and a particular key version that matchesthe source key version; identifying a first encryption key thatcorresponds to the source key name and the source key version;generating a particular decrypted data record by decrypting theparticular encrypted data record using the first encryption key;generating a particular re-encrypted data record by encrypting theparticular decrypted data record using a second encryption key thatcorresponds to the target key name.
 2. The method of claim 1, furthercomprising: storing, in one or more data repositories, alocation-to-key-name mapping that maps the plurality of key names to theplurality of encrypted-data locations.
 3. The method of claim 2, whereinidentifying the particular encrypted data record of the one or moreencrypted data records that is associated with the particular key nameand the particular key version, comprises: using thelocation-to-key-name mapping, determining the one or more encrypted-datalocations of the plurality of encrypted-data locations based on theparticular key name of the plurality of key names.
 4. The method ofclaim 2, further comprising: updating the location-to-key-name mappingwith the target key name and the second encryption key used tore-encrypt the particular decrypted data record.
 5. The method of claim1, wherein each composite value includes payload data; whereingenerating the particular decrypted data record comprises decrypting thepayload data of the composite value of the particular encrypted datarecord using first encryption key.
 6. The method of claim 1, furthercomprising: storing the particular re-encrypted data record at one ofthe one or more encrypted-data locations.
 7. The method of claim 1,further comprising: detecting an error while generating the particulardecrypted data record or while generating the particular re-encrypteddata record; generating a retry message that identifies the error;assigning the retry message to a worker process for retry.
 8. The methodof claim 7, further comprising: generating a retry count based on theretry message and storing the retry count in a database.
 9. The methodof claim 8, further comprising: in response to determining that theretry count is greater than a threshold value, generating and storing afailure message in a database for manual review.
 10. The method of claim1, wherein for each encrypted data record of the one or more encrypteddata records, the key name of the composite value is unencrypted. 11.One or more non-transitory computer-readable media storing instructionswhich, when executed by one or more processors, cause: storing one ormore encrypted data records at one or more encrypted-data locations of aplurality of encrypted-data locations; wherein each encrypted datarecord of the one or more encrypted data records comprises a compositevalue that includes a key name and a key version; receiving a keyrotation request that specifies: a source key name, a source keyversion, and a target key name; wherein the source key name is one of aplurality of key names; in response to receiving the key rotationrequest: identifying a particular encrypted data record of the one ormore encrypted data records; wherein the particular encrypted datarecord is associated with: a particular key name that matches the sourcekey name, and a particular key version that matches the source keyversion; identifying a first encryption key that corresponds to thesource key name and the source key version; generating a particulardecrypted data record by decrypting the particular encrypted data recordusing the first encryption key; generating a particular re-encrypteddata record by encrypting the particular decrypted data record using asecond encryption key that corresponds to the target key name.
 12. Theone or more non-transitory computer-readable media of claim 11, furthercomprising instructions for: storing, in one or more data repositories,a location-to-key-name mapping that maps the plurality of key names tothe plurality of encrypted-data locations.
 13. The one or morenon-transitory computer-readable media of claim 12, wherein identifyingthe particular encrypted data record of the one or more encrypted datarecords that is associated with the particular key name and theparticular key version, comprises: using the location-to-key-namemapping, determining the one or more encrypted-data locations of theplurality of encrypted-data locations based on the particular key nameof the plurality of key names.
 14. The one or more non-transitorycomputer-readable media of claim 12, further comprising instructionsfor: updating the location-to-key-name mapping with the target key nameand the second encryption key used to re-encrypt the particulardecrypted data record.
 15. The one or more non-transitorycomputer-readable media of claim 11, wherein each composite valueincludes payload data; wherein generating the particular decrypted datarecord comprises decrypting the payload data of the composite value ofthe particular encrypted data record using first encryption key.
 16. Theone or more non-transitory computer-readable media of claim 11, furthercomprising instructions for: storing the particular re-encrypted datarecord at one of the one or more encrypted-data locations.
 17. The oneor more non-transitory computer-readable media of claim 11, furthercomprising instructions for: detecting an error while generating theparticular decrypted data record or while generating the particularre-encrypted data record; generating a retry message that identifies theerror; assigning the retry message to a worker process for retry. 18.The one or more non-transitory computer-readable media of claim 17,further comprising instructions for: generating a retry count based onthe retry message and storing the retry count in a database.
 19. The oneor more non-transitory computer-readable media of claim 18, furthercomprising instructions for: in response to determining that the retrycount is greater than a threshold value, generating and storing afailure message in a database for manual review.
 20. The one or morenon-transitory computer-readable media of claim 11, wherein for eachencrypted data record of the one or more encrypted data records, the keyname of the composite value is unencrypted.